home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Arsenal Files 1
/
The Arsenal Files (Arsenal Computer).ISO
/
bbs
/
tm0302.txt
< prev
next >
Wrap
Text File
|
1994-01-23
|
17KB
|
399 lines
SEA Technical Memorandum #0302, GROUP 2.16; Undocumented Features
Last updated: October 14, 1989
Copyright 1988,89 by System Enhancement Associates, Inc.
GROUP 2.16
Undocumented Features
The purpose of this document is to document the undocumented features of
the GROUP GroupMail conferencing program as of version 2.16, released in
October of 1989. These features remain undocumented, even if documented by
this document.
The GroupMail conferencing system is, by design, a pickup system instead
of a delivery system. If at all possible, it should be used as such,
because that is how GroupMail avoids the bulk of the technical problems
associated with echomail.
However, at least one popular network mailer is not capable of properly
negotiating a file update request, which is the mechanism by which
GroupMail functions. Until that can be rectified, GROUP requires some sort
of delivery mechanism in order to link such systems into GroupMail.
If a file named "DELIVER.GRP" is placed in the SEAdog directory, then GROUP
2.16 will use it as a delivery list, and create file attach messages for
each new GroupMail archive as it is posted by GROUP PACK (for a top star)
or GROUP IN (by a middle star). The format of the DELIVER.GRP file will
look very familiar to those acquainted with echomail.
The DELIVER.GRP file is a normal ASCII text file. Each line begins with
the name of a group conference, with the remainder of the line being a list
of network addresses to which it should be delivered. A conference may be
listed more than once, in which case it is addative.
For example, a possible DELIVER.GRP file might be:
BLATZ 520/1015 107/528
GNORF 107/528
GNORF 520/1015
By adding support of a delivery mechanism, we open the door to all the
troubles echomail is heir to. However, the door is open only a tiny crack
at this time. The single biggest problem with a delivery system is that of
faulty topologies that cause duplicate messages. This is largely avoided
from the start because all duplicate GroupMail archives have the same name.
The remaining opportunities for duplicate messages to be generated are
avoided because GROUP 2.16 refrains from unpacking any GroupMail archive
that is older than the "target file" for that conference (unless the /S
option is given).
See also TM0304, "High Volume GroupMail".
GROUP 2.16 implements the following undocumented option switches:
/Q With LIST only. This causes the LIST command to display
conference switches interpretively. GROUP makes certain
"sanity checks" on its conference switches. For example, it
is not possible to have a passthru area if you are the top
star for that area. Executing a GROUP LIST with the /Q
switch will give a report of what switches were active after
all sanity checks and all defaults.
GROUP 2.16 implements the following undocumented command line arguments:
LINK This instructs GROUP to relink the message threads in all of
its message areas. This will also invoke "dup killing" in
ALL areas, not just ones where you are the top star (see
below).
READ This instructs GROUP to load the SEAdog MAIL program if any
messages have been unpacked.
GET <path> This instructs GROUP to seek new GroupMail archives in the
named directory.
CLEAN This instructs GROUP to delete packets on hold that are older
than the specified retention period. This is normally done
automatically when new packets are posted. This command
forces it to happen on demand. This command is used
primarily by Burt Juda in running the EchoGate system.
ASK! This is an emphatic "ask" command, similar to the emphatic
"PACK!" command. It causes GROUP to generate update requests
only for those conferences that are designated with the "/!"
switch. This feature is undocumented because we may decide
to replace it with a more flexible multi-tiered system.
The READ function is especially useful in a "point system", as it allows
for commands of the form:
group ask now in read out now
This causes GROUP to generate file requests, dial out for updates, import
anything it gets, fire up MAIL to read them (if it got anything), export
anything you entered, and then fire up MAILER to ship what you typed (if
anything).
The GET function is especially intended for use on local area networks and
similar environments. It performs a local equivalent of the ASK function.
For example, to obtain and unpack GroupMail archives from another system
whose holding area is accessible via a LAN as G:\MAIL\GRPHOLD, the
appropriate command would be:
group get g:\mail\grphold in
To better facilitate the use of ARCmail for group traffic going to uplinks,
GROUP 2.16 creates and maintains a file called "UPLINKS". After any given
run of GROUP, this file will exist if any traffic to uplinks was found, and
will contain a list of the uplinks concerned. The file will be deleted if
no traffic to uplinks was found. This allows for easy triggering of
ARCmail in a batch file as follows:
group in out
if exist UPLINKS arcmail to UPLINKS
Since ARCmail does not worry about message origins, this has the advantage
of automating the forwarding of middle-star traffic to uplinks.
GROUP keeps track of almost everything in the AREAS.DOG file. However,
there are a few general things it needs to know that can't be stored there.
These are overall system parameters that you won't normally need to do
anything about. But just in case, you can set them from the GROUP system
parameter screen.
You access the system parameter screen by giving the command:
GROUP EDIT
You should then see a screen that looks like this:
Group Mail System Parameters -- Hit ESCape to exit
Link reply threads: YES Move packets on a GET: NO
Scan for duplicates: NO Strip VIA lines on a PACK: YES
Keep outgoing messages: NO Kill messages during PACK: NO
Kill bounceback messages: NO Log descriptions instead of stats: NO
Kill outdated archives: NO Rule posting interval: 30 days
Kill "Ping!" messages: NO Ping interval: 0 days
Name of areas file: AREAS.DOG
Name of statistics log: GROUP.LOG
Name of pickup file: PICKUP.DOG
Name of delivery list: DELIVER.GRP
Name of uplink file: UPLINKS
Name of origin files: ORIGIN
Name of holding directory: GRPHOLD
Group mail staging area #1: GROUP
#2:
#3:
#4:
#5:
#6:
#7:
#8:
#9:
One of the parameters will be highlited. Use your cursor arrows to
highlight the parameter you wish to change, and then type your change. The
various YES/NO parameters are set by hitting either a "Y" (for YES) or an
"N" (for NO). Hit the "Escape" key when you're done.
We'll now go over most of those parameters:
Link reply threads
This tells GROUP if it should relink reply threads in your message
bases after new messages are imported. GROUP does this by default, but
you may want to turn this off if you have a slow disk or a lot of very
large conferences.
Scan for duplicates
This is related to linking reply threads. GroupMail does not normally
have a problem with duplicate messages, but during the interim period
while GroupMail gets connected to echomail, it can "inherit" duplicates
from echomail.
If you set this to "YES", then GROUP will scan for duplicates in any
conference where you are the top star. This will happen automatically
any time messages are imported into your conference.
You can also force this to happen in any and all of your conferences by
giving a GROUP LINK command. In this case, GROUP will scan for
duplicates even if you are not the top star.
Move packets on a GET
This tells GROUP if it should delete the packets it's copied during a
GET command.
Keep outgoing messages
GROUP normally deletes an outgoing message once it's been mailed to
your uplink. If this option is "YES", then GROUP will instead mark the
message as "sent" and leave it.
Kill bounceback messages
As we said, GROUP normally deletes an outgoing message. When the
message returns in the group archive you know everyone got it. If this
option is "YES", then GROUP will discard any messages from your own
system when it unpacks a group archive. If you set the previous option
to "YES" and you leave this option at "NO", you'll end up with two
copies of every message you enter.
Kill messages during PACK
If this option is "YES", then for any conference where you are the top
star GROUP will delete the messages on your system once they have been
packed in a GroupMail archive.
Strip VIA lines on a PACK
If this option is "YES", then for any conference where you are the top
star GROUP will remove any "via lines" from messages as it packs them
in a GroupMail archive. Via lines are hidden notes in the text of a
message that show which systems it has passed through. They can be
useful in diagnosing network topology problems, but removing them will
reduce the size of your GroupMail archives.
Log descriptions instead of stats
When GROUP maintains its log file it calculates several columns of
numbers showing message activity, but it only lists the conferences by
name. If this option is "YES", then GROUP will report conference
activity on a packet basis only, and in the space thus made available
it will report the description of each conference, as it is listed in
your areas file. This can be useful for a passthru midstar.
Kill outdated archives
When GROUP sees an outdated GroupMail archive (i.e. one that you've
already unpacked), it normally prints a warning message and leaves the
archive alone. When this option is "YES", GROUP will automatically
delete outdated archives whenever it sees them. You should not
normally ever see any outdated GroupMail archives.
Rule posting interval
This defines a rule posting interval, in days, for all conferences that
you are the top star for. If you define a rule posting interval, then
GROUP will look in each of your conferences for a text file named
"RULES". If it finds one, then every so many days (defined by your
rule posting interval) it will automatically generate a message in that
conference with the contents of the RULES file as the text of the
message.
Ping interval
This refers to the automatic topology mapping feature of GROUP 2.16.
If you set a non-zero ping interval, then GROUP will "ping" every
conference that you are the top star for every so many days (defined by
the ping interval). This means that your system will create a "ping
message" in each of your conferences, which will cause every member of
your conferences to respond with topology data. The topology data is
then compiled by your system to generate a topology map for your
conference, which becomes the text of your next ping message.
The topology report in your ping message will look something like this:
14d [20] 520/1015
1d [ 3] 107/566, Jim Flowers
1d [29] 41/35, Dale Lovell
1d [14] 440/1, Old Frog
1d [ 3] 520/528
1d 107/528, Burt Juda
1d [14] 520/557, Bill Vanglahn
4h 520/567, Bill Vanglahn
[ 7] 520/583
26m [ 8] 49/2004, John Roberts
Each line reports on one member of your conference. The first column
is the "turnaround time". That is, how long it took for a given system
to respond to your last ping, in days, hours, or minutes. Where this
number is missing, it means that that system is a passthru midstar
whose presence was inferred. The first entry is for your own system,
which by definition has a zero turnaround time, so in this case the
first column is your ping interval.
The number in brackets is the retention period for that system, in
days. Where that number is missing, the system is not a star system
and hence has no retention period.
The rest of the line gives the address and sysop name (where known) for
the system. It is arranged and indented to show the conference
linkages. For example, in this report we can see that 49/2004 (John
Roberts) gets the conference from 520/583, who in turn gets it from the
top star.
Kill "Ping!" messages
If you are a member of one or more conferences where the topstar has
set a ping interval, but you aren't interested in seeing the ping
messages, set this option to "YES".
Name of areas file
This tells GROUP the name of the areas file that lists all of your
group conferences. Normally this is "AREAS.DOG", and it's unlikely
that you'd ever need to change it.
Name of statistics log
This tells GROUP what to call its statistics log. Normally this is
"GROUP.LOG", and is placed in your SEAdog directory.
Name of pickup file
This tells GROUP what to call your pickup list. This is a file
maintained automatically by GROUP which gives the appropriate PICKUP
statements for a SEAdog acting as a star system. This file (normally
called "PICKUP.DOG") should be included in your SEAdog configuration
file with an "INCLUDE" statement.
Name of delivery list
This tells GROUP the name of your delivery list, if any. A delivery
list (normally called "DELIVER.GRP") is similar to another file called
"AREAS.BBS", sort of.
Name of uplink file
This tells GROUP what to call your uplink traffic list. This is a file
maintained automatically by GROUP which gives the network addresses of
any of your uplinks to which you have traffic (the file is deleted if
you have no traffic for any of your uplinks). This is normally called
"UPLINKS", so for example your batch file might contain:
group out
if exist uplinks arcmail to uplinks
Name of origin files
GROUP normally looks for "vanity lines" in a file named "ORIGIN". But
so does some other software. If you have other software that is
looking for ORIGIN files, then you might want to change this so that
GROUP does not "collide" with what your other software expects.
Name of holding directory
This is the name of the directory in which pending GroupMail archives
are kept (unless specified otherwise by the "/D" option). Normally
this is called "GRPHOLD". Archives for passworded conferences are
normally kept in subdirectories of this directory. This only applies
if you are a star in one or more conferences.
Group mail staging areas
A "staging area" is a GroupMail directory. It contains high water
marks and message subdirectories for group conferences. A message area
must be in a GroupMail staging area in order to be considered a
GroupMail area.
You can define up to nine GroupMail staging areas (to put them on
different drives, for example). A "group add" always adds to the last
staging area, and a global ORIGIN file may only be in the first staging
area.
You should NOT remove or change a staging area that has groups in it!
If you really must, then you should delete all of the conferences in
that area, then remove or change that area, then re-add the groups.